…issue. (#9584)

* Remove loose check when assigning non-number inputs

This commit removes a check I added when working on number input
issues where we perform a loose check on an input's value before we
assign it. This prevented controlled text inputs from disallowing
numeric text entry.

I also added a DOM fixture text case.

Related issues:

#9561 (comment)

* Use strict equality as a guard before assigning input.value

This commit adds back the guard around assigning the value property to
an input, however it does it using a strict equals. This prevents
validated inputs, like emails and urls from losing the cursor
position.

It also adds associated test fixtures.

* Add copy command after build for interup with surge.sh

**what is the change?:**
This seems useful, even for this short-lived branch, and some commits we
cherry-picked were making updates to it. So we just pulled the fixture
in from master.

**why make this change?:**
To bring things into a bit more consistency with master.

**test plan:**
Manually tested the fixture - things seem to work.

**issue:**
None - but related to cherry-picking
facebook#9584

Updating the change log~ :)

**issue:**
facebook#9398

Updating the change log~ :)

**issue:**
#9398

This is a follow-up on
#9584 (comment). There
is no need to assign the value property of an input if the value
property of the React component changes types, but stringifies to the
same value. For example:

```javascript
DOM.render(<input value="true" />, el)
DOM.render(<input value={true} />, el)
```

In this case, the assignment to `input.value` will always be
cast to the string "true". There is no need to perform this
assignment. Particularly when we already cast the value to a string
later:

```javascript
// Cast `value` to a string to ensure the value is set correctly. While
// browsers typically do this as necessary, jsdom doesn't.
node.value = '' + value;
```

…issue. (facebook#9584)

* Remove loose check when assigning non-number inputs

This commit removes a check I added when working on number input
issues where we perform a loose check on an input's value before we
assign it. This prevented controlled text inputs from disallowing
numeric text entry.

I also added a DOM fixture text case.

Related issues:

facebook#9561 (comment)

* Use strict equality as a guard before assigning input.value

This commit adds back the guard around assigning the value property to
an input, however it does it using a strict equals. This prevents
validated inputs, like emails and urls from losing the cursor
position.

It also adds associated test fixtures.

* Add copy command after build for interup with surge.sh

This is a follow-up on
facebook#9584 (comment). There
is no need to assign the value property of an input if the value
property of the React component changes types, but stringifies to the
same value. For example:

```javascript
DOM.render(<input value="true" />, el)
DOM.render(<input value={true} />, el)
```

In this case, the assignment to `input.value` will always be
cast to the string "true". There is no need to perform this
assignment. Particularly when we already cast the value to a string
later:

```javascript
// Cast `value` to a string to ensure the value is set correctly. While
// browsers typically do this as necessary, jsdom doesn't.
node.value = '' + value;
```